Micro-payment system architecture

ABSTRACT

A micro-payment system has buyers, sellers, and a broker. The buyers establish accounts with the broker and provide payment information allowing the broker to invoice the buyers. The sellers establish accounts with the brokers and specify terms for accessing items, including electronic content, available from the sellers. The sellers also provide payment information that allows the broker to credit the sellers for sales of the items. The broker aggregates the buyers&#39; micro-payment purchases and invoices the buyers. The broker also aggregates the sellers&#39; micro-payment sales and credits the sellers.

CROSS-REFERENCE TO RELATED APPLICATIONS

This application is a continuation of U.S. patent application Ser. No.13/360,650, filed Jan. 27, 2012, which is a continuation of U.S. patentapplication Ser. No. 13/217,152, filed Aug. 24, 2011, which is acontinuation of U.S. patent application Ser. No. 10/997,227, filed Nov.24, 2004, which claims the benefit of U.S. Provisional Application No.60/605,794, filed Aug. 30, 2004. Each of these applications isincorporated herein in its entirety.

BACKGROUND OF THE INVENTION

1. Field of the Invention

This invention pertains in general to delivery of electronic content andservices over a network such as the Internet and pertains in particularto a system supporting micro-payment mechanisms for the content andservices.

2. Description of the Related Art

Electronic commerce on the Internet has become commonplace. There aremany sellers offering goods and services via web sites on the Internet,and there are an even greater number of buyers who purchase the goodsand services. In many cases, the electronic commerce transactionsinvolve physical goods. For example, many buyers purchase items such asbooks, compact disks (CDs) and DVDs via the Internet. Buyers can alsopurchase electronic content such as downloadable text and/or music andaccess to web sites that provide news or entertainment stories.

Most electronic commerce sites on the Internet use ad hoc purchasingsystems. For example, a web-based music seller typically has apurchasing system that is valid for only that seller's family of websites. Likewise, a seller of web-based electronic content, such asnewspaper stories, typically has a purchasing system that is valid foronly the web site providing the content.

Therefore, a buyer must establish an account and/or provide paymentinformation to each seller that the buyer patronizes. These separateaccounts are inconvenient to both the seller and buyer. The seller mustmaintain a dedicated account management and payment system. The buyermust establish separate accounts, and the attendant login and passwordinformation, with numerous sellers. Moreover, the buyer must engage inrisky behavior, such as providing a credit card number to relativelyunknown sellers, in order purchase items.

The problems described above are especially apparent if the buyerpurchases relatively inexpensive items, such as newspaper stories thatcost only a few cents each. These types of transactions are frequentlyreferred to as “micro-payments.” The transaction cost for most paymentmethods, including credit cards, make the methods impractical for usewith individual micro-payment transactions. Therefore, there is a needin the art for an electronic commerce system that supportsmicro-payments and other types of transactions, but does not suffer fromthe limitations described above.

BRIEF SUMMARY OF THE INVENTION

The above need is met by a micro-payment system utilizing a broker. Inone embodiment, the micro-payment system has multiple buyers andmultiple sellers interacting with at least one broker. The buyersestablish accounts with the broker and provide payment informationallowing the broker to invoice the buyers for aggregate micro-paymenttransactions. The sellers establish accounts with the brokers andspecify terms for accessing items, including electronic content,available from the sellers. The sellers also provide payment informationthat allows the broker to credit the sellers for their sales.

The buyers interact with the broker to purchase items from the sellersin exchange for micro-payments. The broker aggregates the buyers'micro-payment transactions and invoices the buyers for the aggregateamounts of their transactions. The broker also aggregates the sellers'micro-payment sales and credits the sellers for the aggregate amount oftheir sales.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a high-level block diagram of a computing environmentaccording to one embodiment of the present invention.

FIG. 2 is a high-level block diagram illustrating a functional view of atypical computer system for use as one of the entities illustrated inthe environment of FIG. 1 according to an embodiment of the presentinvention.

FIG. 3 is a high-level block diagram illustrating a more detailed viewof a seller of FIG. 1 according to one embodiment of the presentinvention.

FIG. 4 is a high-level block diagram illustrating modules within thebroker of FIG. 1 according to one embodiment of the present invention.

FIG. 5 is a flow diagram illustrating steps performed by buyers,sellers, and the broker according to one embodiment of the presentinvention.

The figures depict an embodiment of the present invention for purposesof illustration only. One skilled in the art will readily recognize fromthe following description that alternative embodiments of the structuresand methods illustrated herein may be employed without departing fromthe principles of the invention described herein.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS A. Overview

FIG. 1 is a high-level block diagram of a computing environment 100according to one embodiment of the present invention. FIG. 1 illustratesa buyer 102, a seller 104, and a broker 106 connected by a network 108.

The buyer 102 in this embodiment represents an entity that obtains itemsvia the network 108 through purchases or other types of transactions.For purposes a clarity, the entity receiving the item from the seller isreferred to as the “buyer” and the transaction is referred to as a“sale” or “purchase.” As used herein, these terms also refer to othertypes of transactions, regardless of whether the entity is technically a“buyer” or the transaction is technically a “sale.”

In one embodiment, the buyer 102 includes a computer system that isutilized by an end-user to communicate with other computers on thenetwork 108 in order to effect a purchase. The computer system, forexample, can be a personal computer executing a web browser such asMICROSOFT INTERNET EXPLORER that allows the end-user to retrieve anddisplay content from web servers and other computer systems on thenetwork 108. In other embodiments, the buyer includes a network-capabledevice other than a computer system, such as a personal digitalassistant (PDA), a cellular telephone, a pager, a television “set-topbox” etc. Although FIG. 1 illustrates only a single buyer 102,embodiments of the present invention can have thousands or millions ofbuyers participating in the electronic commerce system described herein.The single buyer 102 is illustrated in order to simplify and clarify thepresent description. As used herein, the reference number 102 refers toboth a single buyer and/or a set of buyers, depending upon the context.

Similarly, the seller 104 represents an entity that makes itemsavailable on the network 108 via a sale or other type of transaction.For purposes a clarity, the entity offering the item to the buyer isreferred to as the “seller” and the transaction is referred to as a“sale” or “purchase.” As used herein, these terms also refer to othertypes of transactions, regardless of whether the entity is technically a“seller” or the transaction is technically a “sale.”

In one embodiment, the seller 104 includes a computer system acting as aweb server that is utilized by the seller to offer the items topotential buyers 102. The items offered by the seller 104 can includetangible items such as books, CDs, DVDs, electronic goods, etc. Theitems offered by the seller 104 can also include intangible items suchas services and electronic content such as web pages, downloadablefiles, streaming media, etc. For purposes of simplicity and clarity, theremainder of this description assumes the seller is selling electroniccontent. However, one of ordinary skill in the art will understand thatmany different types of items (both tangible and intangible) can be soldby the seller. Although FIG. 1 illustrates only a single seller 104,embodiments of the present invention can have many sellers participatingin the electronic commerce system described herein. The single seller104 is illustrated in order to simplify and clarify the presentdescription. As used herein, the reference number 104 refers to both asingle seller and/or a set of sellers, depending upon the context.

In one embodiment, the seller 104 sells an item for a relativelyinexpensive amount called a “micro-payment.” As used herein, the term“micro-payment” refers to a partial or small amount of currency. Theexact value of a micro-payment depends upon the individual transaction.In one United States embodiment, a typical range for a micro-payment isa fraction of a cent to a few dollars. However, the term “micro-payment”also covers transactions involving smaller or larger payments.

The broker 106 represents an entity that serves as an intermediary forthe transaction between the buyer 102 and the seller 104. In oneembodiment, the broker 106 operates a web site that the buyer 102 canvisit using a web browser and view items for sale by sellers 104. Thebroker 106 provides an electronic commerce payment infrastructure thatallows buyers 102 and sellers 104 to efficiently engage in micro-paymenttransactions. Although FIG. 1 illustrates only a single broker 106,embodiments of the present invention can have multiple brokersparticipating in the electronic commerce system described herein. Thesingle broker 106 is illustrated in order to simplify and clarify thepresent description.

The network 108 represents the communication pathways between the buyer102, seller 104, and broker 106. In one embodiment, the network 108 isthe Internet. The network 108 can also utilize dedicated or privatecommunications links that are not necessarily part of the Internet. Inone embodiment, the network 108 uses standard communicationstechnologies and/or protocols. Thus, the network 108 can include linksusing technologies such as 802.11, integrated services digital network(ISDN), digital subscriber line (DSL), asynchronous transfer mode (ATM),etc. Similarly, the networking protocols used on the network 108 caninclude multiprotocol label switching (MPLS), the transmission controlprotocol/Internet protocol (TCP/IP), the hypertext transport protocol(HTTP), the simple mail transfer protocol (SMTP), the file transferprotocol (FTP), etc. The data exchanged over the network 108 can berepresented using technologies and/or formats including the hypertextmarkup language (HTML), the extensible markup language (XML), etc. Inaddition, all or some of links can be encrypted using conventionalencryption technologies such as the secure sockets layer (SSL), SecureHTTP and/or virtual private networks (VPNs). In another embodiment, theentities can use custom and/or dedicated data communicationstechnologies instead of, or in addition to, the ones described above.

In one embodiment, a seller 104 uses the network 108 to establish anaccount with the broker 106 and specify terms for accessing contentavailable from the seller. The seller 104 also provides paymentinformation that allows the broker 106 to credit the seller 104. Thebroker 106 indexes the content available from the seller 104. The broker106 also provides searching functionality that allows relevant indexedcontent to be identified in response to a search.

A buyer 102 uses the network to establish an account with the broker 106and provide payment information, such as a credit card number, thatallows the broker 106 to invoice the buyer 102. A buyer 102 uses thebroker's search functionality to search for content available fromsellers 104. When a buyer 102 indicates a desire to receive contentavailable from a seller 104, the broker 106 provides the seller'scontent to the buyer. The broker 106 uses the buyer's paymentinformation to charge the buyer a fee for accessing the content and usesthe seller's payment information to share the fee with the seller 104.

B. System Architecture

FIG. 2 is a high-level block diagram illustrating a functional view of atypical computer system 200 for use as one of the entities illustratedin the environment 100 of FIG. 1 according to an embodiment of thepresent invention. Illustrated are at least one processor 202 coupled toa bus 204. Also coupled to the bus 204 are a memory 206, a storagedevice 208, a keyboard 210, a graphics adapter 212, a pointing device214, and a network adapter 216. A display 218 is coupled to the graphicsadapter 212.

The processor 202 may be any general-purpose processor such as an INTELx86, SUN MICROSYSTEMS SPARC, or POWERPC compatible-CPU. The storagedevice 208 is, in one embodiment, a hard disk drive but can also be anyother device capable of storing data, such as a writeable compact disk(CD) or DVD, or a solid-state memory device. The memory 206 may be, forexample, firmware, read-only memory (ROM), non-volatile random accessmemory (NVRAM), and/or RAM, and holds instructions and data used by theprocessor 202. The pointing device 214 may be a mouse, track ball, orother type of pointing device, and is used in combination with thekeyboard 210 to input data into the computer system 200. The graphicsadapter 212 displays images and other information on the display 218.The network adapter 216 couples the computer system 200 to the network108.

As is known in the art, the computer system 200 is adapted to executecomputer program modules. As used herein, the term “module” refers tocomputer program logic and/or data for providing the specifiedfunctionality. A module can be implemented in hardware, firmware, and/orsoftware. In one embodiment, the modules are stored on the storagedevice 208, loaded into the memory 206, and executed by the processor202.

The types of computer systems 200 utilized by the varies entities ofFIG. 1 can vary depending upon the embodiment and the processing powerutilized by the entity. For example, the buyer 102 typically requiresless processing power by the seller 104 and broker 106. Thus, the buyercomputer system can be a standard personal computer system. The sellerand broker computer systems, in contrast, may comprise more powerfulcomputers and/or multiple computers working together to provide thefunctionality described herein.

FIG. 3 is a high-level block diagram illustrating a more detailed viewof the seller 104 according to one embodiment of the present invention.The seller 104 includes a content access control module 302 and acontent database 304. Embodiments of the seller 104 can include otherand/or different modules than the one illustrated in FIG. 3, and thefunctionality attributed to the module can be performed by other ordifferent modules in other embodiments.

The content access control module 302 controls access to the content inthe content database 304. In one embodiment, the content access controlmodule 302 holds authorization and/or authentication information for theentities (e.g., buyers and/or brokers) that have access to the content.This authorization and/or authentication information can include, forexample, login/password pairs, passwords that can be validated usingpublic key cryptography techniques, and/or other data useful forauthorizing and/or authenticating entities having access. If an entityseeking access provides a valid authorization and/or authenticationinformation, the content access control module 302 grants the entityaccess to the content.

In one embodiment, the content access control module 302 also holdsbuyer information allowing the seller to personalize the purchasingexperience for each buyer. This buyer information can include buyerpreferences, references to items previously purchased by the buyer,recommendations for new purchases, etc. In one embodiment, the seller104 provides buyers 102 with “cookies” that unique identify the buyers.A buyer 102 (or broker 106, on the buyer's behalf) provides the cookieto the seller 104 and the seller personalizes the experience for thebuyer identified by the cookie.

The content database 304 stores content made available by the seller104. As used herein, the term “database” refers to a collection ofcontent and does not necessarily refer to a particular organization orstructure of the content. In one embodiment, the content within thecontent database 304 is stored as a collection of discrete data filesarranged in a directory structure. The content can include, for example,a set of one or more web pages defined by HTML and/or XML files, imagefiles such as GIF or JPEG files, JAVASCRIPT files, etc. In addition, thecontent can include portable data files (PDF), executable files, textfiles, media files, and/or any other type of arrangement of data that isaccessible using a computer network. Depending upon the embodiment, thecontent may or may not be protected by a digital rights management (DRM)system.

In one embodiment, a collection of related content is identified by its“realm.” A realm is a reference to a location of content. A universalresource locator (URL) defines a realm. Likewise, a directory path, orpartial path, defines a realm. For example, the URL“http://www.content.provider/paid-content/043ecae9k/” specifies a realmof content located on the server having the domain name“www.content.provider” and located in or below the directory structure“paid-content/043ecae9k.” The following URLs refer to content withinthis realm:

http://www.content.provider/paid-content/043ecae9k/index.html

http://www.content.provider/paid-content/043ecae9k/thumbnail/001.gif

In contrast, the following URLs refer to content outside of this realm:

http://www.content.provider/paid-content/

http://www.content.provider/paid-content/soft03ad

Realms are thus a convenient way to reference content.

FIG. 4 is a high-level block diagram illustrating modules within thebroker 106 according to one embodiment of the present invention.Embodiments of the broker 106 can include other and/or different modulesthan the ones illustrated in FIG. 4, and the functionalities attributedto particular modules can be performed by other or different modules inother embodiments. The modules within the broker 106 allow the broker tointeract with the sellers 104, interact with the buyers 102, and processand account for the sales of content from the sellers to the buyers.

This description first focuses on the modules that allow the broker 106to interact with the sellers 104. The broker 106 includes a selleraccess module 410 which allows a seller 104 to establish an account withthe broker 106. In one embodiment, the seller access module 410 holdsauthorization and/or authentication information for the sellers 104,such as login/password pairs and/or passwords that can be validatedusing public key cryptography techniques. A given seller 104 providesthe authorization and/or authentication information to the broker 106 inorder to log into the broker 106 and provide seller-specificinformation. In one embodiment, the seller-specific information includesa payment mechanism (such as wire transfer address) by which the broker106 can credit the seller 104 for access to the seller's content. Thebroker 106 associates the seller-specific information with theparticular seller having the account. Thus, the seller access module 410allows the creation of separate accounts, and separate sets ofinformation, for each of the sellers 104 that are using the broker 106.

A content rules module 412 stores seller-specified rules describing thecontent available from each seller 104 and the terms of access to thecontent. In one embodiment, the content rules module 412 storesauthorization and/or authentication information that allows the broker106 to log into the content access control module 302 at the seller 104and access the content within the seller's content database 304.

In one embodiment, the seller-specified rules include access rules 414,pricing and payment rules 416, and delivery rules 418. The access rules414 for the content specify the terms of access to the content. Theterms of access describe the content that is available, the time and/orfrequency limits on the access, etc. For example, the terms of accesscan state that a buyer is given one time access to content per purchase.Likewise, the terms of access can state that a buyer can accesspurchased content for a given time period (e.g., 24 hours), can accessthe content in perpetuity, etc. The terms of access can also includemeta-data that define the type of content and/or types of buyers forwhich the content is suitable. For example, the meta-data can indicatethat the content is explicit in nature and suitable for adults.

In one embodiment, the access rules 414 also specify relationshipsbetween the content. In an embodiment where the content comprises webpages, the terms of access can specify that certain text and images areprovided as part of the page, and/or are available to a buyer whopurchases a given page. For example, if the buyer purchase a web pagehaving a thumbnail image, the terms of access can specify that the buyeris also entitled to view a larger version of the image stored in theseller's content database 306.

The pricing and payment rules 416 specify the fees associated withaccessing the content from the seller 104. Depending upon the embodimentand/or the seller 104, the fees can be based on a frequency of access,based on a time period of access, based on the types and/or amount ofcontent accessed, and/or any other factors. For example, the pricingrules 416 can specify that a buyer is charged 0.1 cent per access to aparticular piece of content. Similarly, the pricing rules 416 canspecify that a buyer is charged $5/week to access all content from theseller 104. Those of skill in the art will recognize that manyvariations of pricing are possible.

In one embodiment, the pricing and payment rules 416 also specify thepayments to be made from the broker 106 to the seller 104 in return foraccess to the content. In one embodiment, the fees charged to the buyer102 are shared between the broker 106 and the seller 104 and the pricingand payment rules 416 thus specify how the fees are to be shared. Thefee sharing terms can vary depending upon the buyer, seller, contentbeing purchased, frequency that the content is purchased, or any otherfactors established by the broker 106 and/or seller 104. In oneembodiment, the pricing and payment rules 416 specify a percentage splitbetween the broker 106 and seller 104.

The delivery rules 418 for the content describe how content is deliveredto the buyer. In one embodiment, the delivery rules 418 indicate whetherparticular content is cached at the broker 106 and/or whether the buyeris provided with direct access to the seller 104. In one embodiment, thedelivery rules 418 indicate whether the broker 106 should obscure asource of content delivered to a buyer 102.

In one embodiment, the content rules module 412 specifies contentassociated within given access 414, pricing 416, and/or delivery 418rules using realm descriptions. A realm description identifies a realmof content, and a set of access, pricing, and/or delivery rules that areapplicable to the content within the realm. Other embodiments usedifferent techniques for specifying content for which given rules areapplicable.

This description next turns to the modules that allow the broker 106 tointeract with the buyers 102. In one embodiment, the broker 106 includesa buyer access module 420 which allows a buyer 102 to establish anaccount with the broker 106. In one embodiment, the buyer access module420 holds authorization and/or authentication information for the buyers102, such as login/password pairs and/or passwords for use in a publickey cryptography system. A given buyer 102 provides the authorizationand/or authentication information to the broker 106 in order to log intothe broker 106 and provide buyer-specific information. In oneembodiment, the buyer-specific information includes payment information422 (such as a credit card number) that allows the broker 106 to chargethe buyer 102 for content. The broker 106 associates the buyer-specificinformation with the particular buyer having the account. Thus, thebuyer access module 420 allows the broker 106 to establish separateaccounts, and separate sets of information, for each of the buyers 102that are using the broker. In one embodiment, the buyer-specificinformation includes parental-control information and the like thatblocks the buyer from buying undesired content.

In one embodiment, the buyer-specific information also includes billingrules 424 for the buyer 102. The billing rules specify the billing termsfor the buyer including, for example, the length of the billing cycle(e.g., weekly or monthly) and/or the minimum amount of a bill (e.g.,invoice the buyer 102 when the accumulated cost of the buyer'stransactions exceed $20). The billing rules can also specify apre-approval amount (e.g., automatically approve all transactions under10 cents, but seek approval for more costly transactions).

In one embodiment, the buyer-specific information includes notificationrules 426 specifying if and/or when a buyer 102 should be notified aboutpurchases. For example, the notification rules can specify to send anemail to the buyer 102 each time the buyer purchases content, and/or tosend an email when the total value of the content purchased exceeds aspecified amount. Similarly, the notification rules can display a noticeto the buyer 102 if the buyer attempts to purchase content having a costabove a specified limit. Other embodiments of the present invention canhave different and/or other billing and notification rules than the onesdescribed herein.

This discussion now turns to the modules that process and account forthe sales of content from the sellers to the buyers. In one embodiment,the broker 106 includes a content indexing module 428 that indexes thecontent available from the sellers 104. In one embodiment, the contentindexing module 428 uses the authorization and/or authenticationinformation provided by the sellers 104 to log into the sellers andaccess the content available there. The content indexing module 428indexes the content by keyword and/or other criteria that allow thecontent to be quickly identified and/or retrieved in response to a queryfor which the content is responsive. In one embodiment, a crawler module430 within the content indexing module 428 methodologically identifiesthe content at the seller 104 by following links within the content toother content that in turn has additional links. By following the links,the crawler module 430 can identify all (or at least the linked-tosubset) of the content available from the seller 104.

In one embodiment, a searching interface module 432 provides the buyers102 with access to content searching capabilities. These capabilitiesallow a buyer 102 to provide the searching interface module 432 with asearch query that specifies search parameters such as keywords,meta-data describing desired results, and/or other information andreceive in return a list of content that at least partially satisfiesthe query. In one embodiment, the search query is generated implicitlybased on actions performed by the buyer 102 and/or other criteria. Inone embodiment, the searching interface module 432 interfaces with asearch engine 434 provided by GOOGLE INC. of Mountain View, Calif. Thesearch engine 434 searches the content indexed by the content indexingmodule 428 in response to search queries from buyers 102 and identifiescontent that satisfies the queries. In one embodiment, the search engine434 also searches content in other domains, such as content freelyavailable on the Internet.

The search engine 434 thus identifies a list of content that at leastpartially satisfies a query. In such an embodiment, the result of aquery can include a mix of premium (i.e., content for sale from sellers104) and free content. In one embodiment, sellers 104 can purchaserights to terms utilized in the search query. If the buyer 102 searchesfor a term purchased by a seller 104, the search engine 434 (or anothermodule working in concert with the search engine 434) returns areference to that seller's content to the buyer along with the otherresults of the search.

The searching interface module 432 presents the buyer 102 withdescriptions of the content identified by the search. There are avariety of ways that the searching interface module 432 can presentthese search results to a buyer 102. In one embodiment, the results arepresented visually. In another embodiment, the results are presentedaudibly. In one embodiment, the results for premium content aredisplayed inline with results for free content. In another embodiment,the searching interface module 432 segregates the premium content fromthe free content. For example, the premium content can appear as aseparate results list and/or as a series of advertisements. In oneembodiment, the searching interface module 432 provides a buyer 102 withan excerpt of the premium content to allows the buyer to evaluatewhether purchasing the premium content is justified. In one embodiment,the searching interface module 432 provides a buyer with a reputationscore for the premium content and/or seller 104 offering the content.The reputation score, which is calculated by the reputation module 444described below, is a value indicating the relative quality of thepremium content and/or the seller of the content.

In one embodiment the broker 106 includes a content proxy module fordelivering content to the buyers 102. When a buyer 102 indicates adesire to purchase content, the content proxy module 436 evaluates theinformation and rules in the buyer access module 420 to determinewhether the buyer is entitled to receive the content. If the buyer 102is entitled to receive the content, the content proxy module 436provides the content to the buyer.

Depending upon the embodiment, there are multiple ways that the contentproxy module 436 can provide the content to the buyer 102. In oneembodiment, the content proxy module 436 provides the buyer 102 withinstructions for retrieving the content directly from the seller 104.These instructions can be encoded in a HTTP instruction (such as a“redirect” instruction) and/or a URL so that the content access appearsseamless to the buyer 102. In another embodiment, the content proxymodule 436 uses the information in the seller access module 410 and/orthe content rules module 412 to retrieve the content from the seller 104and provide it to the buyer. In one embodiment, the content proxy module436 includes a content cache 438 for storing content retrieved from thesellers 104. When a buyer 102 purchases content that is stored in thecache 438, the content proxy module 436 provides the buyer with thecached content rather than retrieving the content from the seller 104.

In one embodiment, the content cache 438 is loaded with content when thecontent indexing module 428 indexes the content at the sellers 104. Inanother embodiment, the content cache 438 stores a copy of content whenpreviously-uncached content is retrieved from a seller 104 in responseto a purchase by a buyer 102. The content proxy module maintainscoherency between the cached content and the content at the sellers 104by occasionally evaluating the cached content and flushing stale contentor using other known cache coherency techniques.

In one embodiment, the content proxy module 436 acts as an opaque proxyand obscures the true source of purchased content from the buyers 102.For example, if the true URL of content purchased by a buyer 102 is

“http://premiumcontent.seller.com/premiumcontent,” the content proxymodule rewrites the URLs of content received by the buyer so that thecontent appears to come from another source such as“http://premiumcontent.broker.com/contentID.” The content proxy module436 also rewrites any URLs within the content and fixes up any relativeURLs in the content as may be necessary or desired to obscure its sourceof origin.

In one embodiment, the content proxy module 436 includes a cookie cache440 for maintaining cookies on behalf of buyers 102 and sellers 104. Acookie is data that unique identifies a buyer 102. In a normal webbrowsing scenario without a broker 106, a seller 104 can cause a buyer'sweb browser to store a cookie identifying the buyer to the seller. Theseller 104 can use the cookie to identify the buyer 102 and customizethe buyer's experience when interacting with the seller.

In one embodiment of the present invention, however, the buyer 102 andseller 104 do not directly interact and, therefore, the seller 104cannot place or read a cookie at the buyer 102. The cookie cache 440therefore maintains a correspondence between the buyers and the cookiesissued by the sellers. When the broker 106 facilitates an interactionbetween a buyer 102 and a seller 104, the content proxy module 436identifies the buyer using the information in the buyer access module420 (and/or via a broker cookie) and identifies a corresponding cookieissued by the seller for that buyer. Then, the content proxy module 436supplies the cookie to the seller 104. The cookie cache 440 thus allowsthe seller 104 to identify its buyers, but still provides anonymity onbehalf of the buyers and sellers.

In one embodiment, the broker 106 includes a refund module 442 thatallows buyers 102 to obtain refunds for content they have purchased. Therefund module 442 includes logic specifying if and/or when a buyer 102is entitled to a refund. For example, the logic can specify that refundsare not available for certain content, that refunds are available withina certain time period of purchase, refunds are available before theoccurrence of a certain event (e.g., before the buyer's credit card ischarged) etc. In one embodiment, the logic within the refund module 442is determined by the content rules in the content rules module 412. Inanother embodiment, the refund logic is set by the broker 106.

In one embodiment, the refund module 442 provides a buyer 102 with aninterface that allows the buyer to request refunds for eligiblepurchases. In one embodiment, the refund module 442 provides the buyer102 with a web page that lists the buyer's recent transactions andallows the buyer to request refunds for given transactions. In anotherembodiment, the refund module 442 detects if a buyer 102 has performedan action that triggers a refund, such as selecting a “back” button of aweb browser immediately after purchasing content.

In one embodiment, the refund module 442 also supports resolution ofdisputes between a buyer 102 and seller 104 regarding a purchasetransaction. To this end, the refund module 442 provides the buyer 102and seller 104 with web pages that collect evidence related to thedispute and then present the evidence to a third party. The third partyreviews the evidence and resolves the dispute, and interacts with therefund module 442 as may be necessary or desired to effect resolution ofthe dispute.

In one embodiment, the broker 106 includes a reputation module 444 thatprovides a reputation score indicating the relative quality of contentand/or the sellers 104 that provide the content. In one embodiment, thereputation score is determined automatically in response to actions thatoccur at the broker 106. For example, the reputation module 444 can givea higher to reputation score to content that is purchased morefrequently relative to other content. Likewise, the reputation module444 can give a higher reputation score to a seller 104 that sells morecontent relative to other sellers. Furthermore, the reputation module444 can reduce the reputation score of content for which refunds arefrequently requested, and/or reduce the reputation score of sellers 104that sell frequently-refunded content. In addition, the reputation scorecan be determined in response to buyer input. In one embodiment thereputation module 444 provides buyers 102 with an interface with whichthe buyers can provide feedback and assign reputation scores to contentand/or sellers. The reputation module 444 aggregates the scores assignedby the buyers 102 and calculates reputation scores for the contentand/or sellers.

In one embodiment, the broker 106 includes a fraud detection module 446for detecting potentially fraudulent usage of the broker 106. One knownway to abuse the broker 106 is to establish a fraudulent seller 104 andhave a buyer 102 make multiple content purchases from that seller usinga stolen credit card number. In such a scenario, the operator of thefraudulent seller 104 could conceivably collect the seller's portion ofthe fees billed by the broker 106 to the stolen credit card. The frauddetection module 446 is adapted to detect this and other types of fraud.In one embodiment, the fraud detection module detects when a rate oftransactions by a particular buyer and/or seller exceeds a certainvalue, such as a historical average. Such a high rate of transactionscan indicate that the transactions are fraudulent. In one embodiment,when the fraud detection module 446 detects potential fraud of thistype, it reacts by slowing down the rate of transactions that can beperformed by the potentially-fraudulent buyer 102 and/or seller 104. Ifthe potentially-fraudulent activity continues, the fraud detectionmodule 446 eventually denies all transactions by thepotentially-fraudulent buyer 102 and/or seller 104.

In one embodiment, an accounting module 448 monitors the transactionsthat occur using the broker 106, invoices the buyers according to theinformation in the buyer access module 420, and credits the sellersaccording to the information in the seller access 410 and content rulesmodules 412. In addition, the accounting module 448 also accounts forrefunds requested and received. Thus, the broker 106 supports amicro-payment marketplace between buyers 102 and sellers 104.

In one embodiment, the accounting module 448 aggregates the purchasesmade by respective buyers 102 and maintains a running total of eachbuyer's purchases within a billing cycle. For example, if the buyer 102purchases multiple news story at a cost of 10 cents each, the accountingmodule 448 maintains the sum of the buyer's purchases for the pertinentbilling cycle. Information within the buyer access module 420 orelsewhere within the broker 106 specifies when to invoice (e.g., charge)the buyer 102 for the amount of the aggregate purchases, at which pointthe billing cycle restarts.

In one embodiment, a buyer 102 establishes credit with the broker 106which is maintained, for example, within the buyer access module 420and/or the accounting module 448. The accounting module 448 subtractsthe buyer's purchases from the established credit. When the credit isspent, the broker 106 can charge additional credit using the buyer'spayment information 442 and/or interacts with the buyer 102 to establishnew payment terms.

In one embodiment, the accounting module 448 similarly aggregates thesales made by respective sellers 104 and maintains a running total ofeach seller's sales within a credit cycle. Information within the selleraccess module 410, content rules module 412, the accounting module 448,or elsewhere within the broker 106 specifies when to credit the seller104 for the seller's share of the fees generated by the aggregatepurchases, at which point the credit cycle restarts.

C. Process/Example

FIG. 5 is a flow diagram illustrating steps performed by buyers 102,sellers 104, and a broker 106 according to one embodiment of the presentinvention. Those of skill in the art will recognize that in someembodiments the steps will not be performed in the order illustrated inFIG. 5. In addition, some embodiments will lack certain steps and/orcontain different steps than the ones illustrated in FIG. 5.

At some point, a buyer 102 establishes 510 an account with the broker106. Typically, the buyer 102 will perform this step by using a webbrowser to connect to a web site operated by the broker 106, set up anaccount, and provide a credit card number or other payment information.Similarly, at some point a seller 104 establishes an account with thebroker 106. The seller 104 can also perform this step by using a webbrowser to connect to a web site operated by the broker 106, set up anaccount, and provide the content rules and other information utilized bythe broker.

The broker 106 indexes 514 the content available from the seller 104. Inone embodiment, the broker 106 indexes the content immediately after theseller establishes an account. In another embodiment, the broker 106periodically indexes content from all sellers having accounts with thebroker. Regardless of when the indexing occurs, at some point the broker106 has indexed the content and incorporated the content into theuniverse of data that can be returned to buyers in response to searchqueries.

The buyer 102 uses the searching interface module 434 to execute 516 aquery searching for content, such as web pages or PDF files, matchingthe search terms. In response, the broker 106 returns a list of searchresults that may include free and/or premium content. As discussedabove, the search results can intermingle the free and premium contentresults, or the different types of results can be segregated anddisplayed in different manners. In addition, the premium content searchresults can include excerpts from the premium content. Furthermore, thepremium content search results can include a graphical or textualindicator of the reputation score for the premium content and/or seller104. In an alternative embodiments, the buyer 102 is presented with alist of premium content in response to an activity other than executinga query. For example, the buyer 102 can navigate a content directory tofind the list.

The buyer 102 selects and purchases 518 content from the list presentedby the broker 106. In one embodiment, the buyer 102 uses the web browserto select and “click” on a link to the content. This activity causes aURL identifying the buyer 102 and/or content to be sent from the buyer'sweb browser to the broker 106. This URL is received by the content proxymodule 436.

The content proxy module 436 examines the information in the contentrules module 412 and buyer access module 420 and determines whether thebuyer 102 is allowed to access the content. For example, meta-dataassociated with the content might not satisfy parental controlinformation specified by the buyer 102 and, therefore, the content proxymodule 436 will deny the transaction and block access to the content. Inanother example, the buyer's payment information 422 and/or billingrules 424 might prevent the buyer from purchasing the content if thecontent is too expensive. During this process, the content proxy module436 might also determine that the buyer 102 has already purchased thecontent and is allowed by the seller's access rules 414 to access thecontent again without charge.

If the buyer 102 is allowed to access the content, the content proxymodule 436 provides 520 the content to the buyer 520. In one embodiment,the content proxy module 436 sends the buyer 102 a URL pointing to thecontent. Depending upon the embodiment, the URL can point to contentwithin the content cache 438, content at the seller 104, and/or contentlocated elsewhere on the network 108. In addition, the content proxymodule 436 can configure the URL, and rewrite any URLs in the content,to obscure the true source of the content. The buyer 102 uses the URL toretrieve the content. In one embodiment, the content proxy module 436retrieves the buyer's seller cookie from the cookie cache 440 andprovides it to the seller 104 to allow the seller 104 to customize thecontent for the buyer.

The broker 106 invoices 522 the buyer for the purchase and credits theseller 104 for the transaction. In one embodiment, the broker 106aggregates the charges for the buyer as specified in the buyer accessmodule 420. When a billing condition is met, such as the total chargesreaching a specified amount or the end of a billing cycle, the broker106 invoices the buyer 102. This invoicing can occur, for example, bysending an invoice to the buyer 102, charging the buyer's credit card,etc. In another embodiment, the broker 106 separately charges the buyer102 for each transaction (or for certain transactions). If necessary ordesired, the buyer 102 can seek a refund for the transaction byinteracting with the refund module 442.

In one embodiment, the broker 106 also aggregates the credits for theseller 104. When a crediting condition occurs, such as the total creditsreaching a specified amount or the end of a crediting cycle, the broker106 credits the seller 104 using the payment mechanism as specified bythe seller in the seller access module 410. In another embodiment, thebroker 106 credits the seller 104 during each transaction. As describedabove, in one embodiment the broker 106 and the seller 104 share thefees paid by the buyer 102 for the content.

The above description is included to illustrate the operation of thepreferred embodiments and is not meant to limit the scope of theinvention. The scope of the invention is to be limited only by thefollowing claims. From the above discussion, many variations will beapparent to one skilled in the relevant art that would yet beencompassed by the spirit and scope of the invention.

1. A computer-implemented method comprising: establishing an account fora seller with a broker, the seller selling electronic content that canbe purchased by buyers, the seller including a content database storingelectronic content offered by the seller; storing in a storage system ofthe broker and separate from the content database of the seller, a copyof the electronic content offered by the seller; receiving a searchquery from a buyer; searching for electronic content responsive to thesearch query; and presenting the buyer with a description of theelectronic content responsive to the search query.
 2. The method ofclaim 1, wherein presenting the buyer with a description comprises:presenting the buyer with descriptions of free electronic content andpremium electronic content that are responsive to the search query. 3.The method of claim 2, wherein presenting the buyer with a descriptioncomprises: providing the buyer with a reputation score indicating arelative quality of the premium electronic content.
 4. The method ofclaim 1, further comprising: responsive to the buyer purchasing theelectronic content, providing the purchased electronic content from thestorage system to the buyer.
 5. The method of claim 4, wherein the buyermakes multiple purchases of electronic content from the broker andfurther comprising: aggregating multiple purchases of electronic contentfrom the broker made by the buyer within a billing cycle; and invoicingthe buyer for an amount of the multiple purchases made within thebilling cycle.
 6. The method of claim 1, further comprising: storing arule describing terms of access to the electronic content; allowing thebuyer to purchase the electronic content; and providing the buyer withthe purchased electronic content responsive to the terms of accessdescribed by the rule.
 7. The method of claim 1, wherein presenting thebuyer with a description of the electronic content comprises: providingthe user with an excerpt of the electronic content.
 8. A non-transitorycomputer-readable storage medium having executable computer programlogic embodied therein, the computer program logic executable to performsteps comprising: establishing an account for a seller with a broker,the seller selling electronic content that can be purchased by buyers,the seller including a content database storing electronic contentoffered by the seller; storing in a storage system of the broker andseparate from the content database of the seller, a copy of theelectronic content offered by the seller; receiving a search query froma buyer; searching for electronic content responsive to the searchquery; and presenting the buyer with a description of the electroniccontent responsive to the search query.
 9. The computer-readable mediumof claim 8, wherein presenting the buyer with a description comprises:presenting the buyer with descriptions of free electronic content andpremium electronic content that are responsive to the search query. 10.The computer-readable medium of claim 9, wherein presenting the buyerwith a description comprises: providing the buyer with a reputationscore indicating a relative quality of the premium electronic content.11. The computer-readable medium of claim 8, the computer program logicexecutable to perform steps further comprising: responsive to the buyerpurchasing the electronic content, providing the purchased electroniccontent from the storage system to the buyer.
 12. The computer-readablemedium of claim 11, wherein the buyer makes multiple purchases ofelectronic content from the broker and further comprising: aggregatingmultiple purchases of electronic content from the broker made by thebuyer within a billing cycle; and invoicing the buyer for an amount ofthe multiple purchases made within the billing cycle.
 13. Thecomputer-readable medium of claim 8, the computer program logicexecutable to perform steps further comprising: storing a ruledescribing terms of access to the electronic content; allowing the buyerto purchase the electronic content; and providing the buyer with thepurchased electronic content responsive to the terms of access describedby the rule.
 14. The computer-readable medium of claim 8, whereinpresenting the buyer with a description of the electronic contentcomprises: providing the user with an excerpt of the electronic content.15. A computer system comprising: a computer processor for executingcomputer program logic; and a non-transitory computer-readable storagemedium having executable computer program logic embodied therein, thecomputer program logic executable by the processor to perform stepscomprising: establishing an account for a seller with a broker, theseller selling electronic content that can be purchased by buyers, theseller including a content database storing electronic content offeredby the seller; storing in a storage system of the broker and separatefrom the content database of the seller, a copy of the electroniccontent offered by the seller; receiving a search query from a buyer;searching for electronic content responsive to the search query; andpresenting the buyer with a description of the electronic contentresponsive to the search query.
 16. The computer system of claim 15,wherein presenting the buyer with a description comprises: presentingthe buyer with descriptions of free electronic content and premiumelectronic content that are responsive to the search query.
 17. Thecomputer system of claim 16, wherein presenting the buyer with adescription comprises: providing the buyer with a reputation scoreindicating a relative quality of the premium electronic content.
 18. Thecomputer system of claim 15, the computer program logic executable toperform steps further comprising: responsive to the buyer purchasing theelectronic content, providing the purchased electronic content from thestorage system to the buyer.
 19. The computer system of claim 18,wherein the buyer makes multiple purchases of electronic content fromthe broker and further comprising: aggregating multiple purchases ofelectronic content from the broker made by the buyer within a billingcycle; and invoicing the buyer for an amount of the multiple purchasesmade within the billing cycle.
 20. The computer system of claim 15, thecomputer program logic executable to perform steps further comprising:storing a rule describing terms of access to the electronic content;allowing the buyer to purchase the electronic content; and providing thebuyer with the purchased electronic content responsive to the terms ofaccess described by the rule.